With increasing global competition, corporations today are facing new challenges in bringing their products and services to market. The globalization of today's corporations, decentralization of corporate operations, and the accelerated rate of change in markets and competition are all factors representing both challenges and opportunities for today's businesses.
Modern companies are increasingly becoming information-based organizations, dependent upon the continuous flow of data for virtually every aspect of their operations. However their ability to handle data is breaking down because the volume of information is growing at a faster rate than their ability to process it. Further complicating matters is the difficulty that traditional monolithic applications have in representing an organization's business processes effectively — particularly as those processes or the organization itself changes.
Networked object technology such as Solaris NEO represent the best opportunity to meet the demands of agile organizations. Solaris NEO applications can effectively encapsulate business practices, policies, and tactics in modular components engineered to be re-engineered. Fast prototyping and updating capabilities encourage a development model that can design, test, and deploy a new application in less time and with less effort than traditional development methods. With Solaris NEO, legacy software can be encapsulated in objects, retaining its semantics and continuing to serve its users while it gracefully evolves into a fully networked application.
To facilitate this streamlined approach to object application development, Solaris NEO provides a robust and complete infrastructure for shared networked services, including access to stored data, and a consistent, intuitive, rich graphical interface that facilitates the rapid development of new applications.
Solaris NEO provides an extensive foundation of reusable components that form the basis for building new applications. Services to support the presentation and management of networked applications are built into its runtime environment, as are objects which can exploit Solaris' advanced multithreading capability. Building on these existing services encourages modification through a refinement development model that produces applications quickly, reducing the application development backlog that has troubled many MIS organizations.
Advanced productivity tools available in Workshop NEO enable team software development with an object-oriented interface builder that speeds and simplifies the building of prototypes. Promotion of, and conformance to, industry standards further ensures connectivity with mainframes as well as with MS-Windows based desktops. Further, database connectivity and built-in persistence and encapsulation methods provide easy access to legacy data.
Figure 2 illustrates the five key dimensions of the NEO Product Family. Together, Solaris NEO, Solstice NEO, WorkShop NEO, and complementary
MS-Windows and database connectivity technology, provide a comprehensive solution for enterprise application systems.
A major benefit of truly heterogeneous networked objects is the ability to integrate disparate platforms, allowing information resources to be shared across the network, independent of specific operating systems, languages, or implementation techniques. The cornerstone of this effort is the method by which interfaces to objects are defined, allowing behavior to be characterized without specifying the method used to implement it. Evidence of its commitment to both standards and object technology, SunSoft contributed the Interface Definition Language (IDL) to the OMG.
Through the availability of a standardized Inter-ORB Protocol (IOP), vendors can supply objects that interoperate in a heterogeneous environment. OMG's CORBA 2.0 standard Internet IOP (IIOP) is based on TCP/IP, and SunSoft provides a sample reference implementation free of charge, thus enabling vendors to be certain that their systems, objects and applications are interoperable.
NEO Desktop provides the user with the same functionality as the NeXTSTEP Application Environment. In addition, NEO Desktop enables the continued use of the thousands of existing applications available for Solaris today. As an integral part of SunSoft's `universal desktop', this includes use of Common Desktop Environment (CDE) applications, MS-Windows applications using Wabi, and Apple® Macintosh® applications running under the Macintosh Application Environment (MAE). Interoperability such as drag-and-drop and cut-and-paste is supported between applications from all of these different environments. In addition to OpenStep applications, WABI, MAE, and
CDE-Motif applications can be launched from the NEO Desktop. In turn, OpenStep applications can be launched from the CDE desktop.
NEO Desktop delivers a rich visual environment based on X11 with Display PostScript™ extensions and provides an intuitive, easy to use, high quality, multimedia user environment. Informative active icons, advanced drag and drop support, embedded multimedia capabilities, and integrated help facilities enhance the user experience and productivity. Interface consistency aids users in adapting to employing new applications quickly, and productivity is improved because the same functionality is available for all desktop applications. As an example, the NEO Desktop spell checker may be invoked from the text edit and electronic mail desktop applications, or any other custom application.
NEO Network's advanced technology is scalable, high performance and designed to form a solid platform for shared service computing. Networked administration and management facilities are built-in. In addition, NEO Network is architected to enable future system evolution.
NEO Services automates and makes transparent functions that an application developer would normally need to write for areas including shared services, server availability, persistent object availability, concurrent requests, server management, and application installation. It enables full, simplified use of the NEO networked object infrastructure.
Completely unique to Solaris NEO, NEO Services is fully compatible with CORBA specifications, and provides the extended services required to facilitate rapid development of networked applications.
Solstice NEO, bundled with Solaris NEO, complements this strategy and adds capabilities for the administration and management of networked applications and shared services to the Solstice product family. With Solstice NEO, resources can be monitored and controlled from any point on the network. System, workgroup, shared service, and application management capabilities are supported in the areas of:
Figure 5 illustrates the component structure of WorkShop NEO. For additional details, consult the WorkShop NEO Development Environment Product Overview whitepaper.
Complementary technology from IONA Technologies, in combination with Solaris NEO, provides connectivity with MS-Windows desktops including interoperability with OLE and the underlying Component Object Model (COM). This technology, based on IONA's Orbix product, allows
MS-Windows applications to access NEO objects and shared services and act as networked enterprise application front-ends. Network communication is based on OMG's CORBA 2.0 Interoperability specifications (see Figure 6).
Complementary technology from Persistence Software, in combination with Solaris NEO, provides mechanisms for automatically mapping objects to relational tables, ensuring data integrity by enforcing object constraints and controlling relational transactions, as well as scaling to multiprocessor and multiple database implementations.
As a founder of the Object Database Management Group (ODMG), SunSoft is promoting standards for interoperability between OODBMS providers. The ODMG-93 specification defines interfaces to object databases that ensure heterogeneous interoperability, object portability and reuse, as well as concurrent access.
The NEO Desktop is a user-friendly OpenStep-based application environment consisting of the following elements:
The common desktop services are usable by any OpenStep application at runtime. These services, accessed programmatically via OpenStep frameworks, include pasteboard (for cut and paste), drag and drop, hyperlinks, spell checker, and print.
The NEO Desktop also provides interoperability with other ICCCM-compliant application environments. WABI, MAE, CDE-Motif and OpenStep applications can be launched from the NEO Desktop. In turn, OpenStep-based applications can be launched from the CDE desktop.
The NEO Desktop Window Manager is a X11-based ICCCM-compliant window manager. This provides consistency and interoperability in the areas of:
Figure 7 illustrates the NEO Desktop Workspace Manager.
The OpenStep component of NEO consists of OpenStep-compliant development frameworks and associated shared libraries that make up the OpenStep runtime system in Solaris NEO.
The OpenStep frameworks, supplied as Objective C class libraries, comprise the following:
AppKit is similar in overall function to the CDE-Motif toolkit. It incorporates DPS rendering within top level X Windows and supports Alpha compositing. It provides extremely sophisticated shading and transparency effects beyond the simple 3D shading provided by most X Windows toolkits. Other extended features include support for lower level data types available in the OpenStep Foundation Framework (implemented as the FoundationKit class library).
Table 1: OpenStep GUI Framework objects and their classes
Image classes support both TIFF and EPS formats. Predefined window panels for incorporation in applications are provided for selecting colors and PostScript fonts, and controlling font size, weight, and other properties.
Table 2: OpenStep Application Framework objects and their classes
Table 3: OpenStep Foundation Framework objects and their classes
The NEO Network component of Solaris NEO is an OMG CORBA-compliant networked object infrastructure consisting of an Object Request Broker (ORB) and set of object services. NEO Network is mature, tested technology. The NEO Early Developers Release (EDR) was first distributed in June 1993, followed by EDR-2 in May of 1994.
NEO Network provides a robust, networked object infrastructure that enables object-to-object communication. It is the traffic controller and message router between objects and provides application developers with the services necessary to create systems of cooperating objects, shared services, and integrated networked applications.
The design center of NEO Network can be summarized as follows:
Networked objects have OMG IDL interfaces and are accessed using an object reference.
Networked services (or simply services) are collections of networked objects that provide coherent chunks of shared functionality for clients.
Factories are services that create objects.
Server programs are executables that contain the implementations for one or more object types.
Server processes (or simply servers) are server programs running in a Solaris process.
Object instances (or simply objects) are specific instantiations of an object type with its own state.
NEO Network supports flexible activation of server processes, object implementations, and objects. Objects and server processes can be deactivated manually or automatically by setting an idle timeout. Queued requests are sent to a newly activated server process. Client programs notice nothing other than a slight delay.
All NEO object references are automatically persistent across server process activations which means that client programs do not need to maintain any additional information about objects in order to access them. NEO Network also provides a form of fine-grained object — subobjects — which are particularly useful for the efficient support for large numbers of objects stored in databases. An unlimited number of subobjects can share the normal memory and resources required for a single object reference.
Overhead in the NEO Network ORB has also been minimized. Once communication is established between the client and the server process, the ORB gets out of the way. NEO Network features same-process and inter-process optimization. Networking code is bypassed for same-process objects and shared memory is used. Extensive caching is done to optimize such things as location lookup, connection reuse, and object adapter information. Subobjects allow faster access to fine-grain objects. From the client program point of view, object references for subobjects are indistinguishable from normal objects.
A rich set of object services is included that form building blocks for applications composed of networked objects. These services also form the basis for application interoperability and integration. Generic tools and frameworks can be developed to use and manipulate objects and services that conform to the standardized object service interfaces — without any other special additional knowledge about their functionality. Sun `Level 4' internationalization is also supported.
NEO Network's use of and support for opaque object references is crucial for making transparent changes in such areas as security and replication support and for providing dynamic system upgrades. The internal architecture of NEO Network is based on virtual layering techniques that allow future transparent introduction of capabilities such as object and service replication and high availability. In addition, all NEO Network protocols and file formats are versioned. The system is designed to be dynamically upgradable.
Security is a key aspect of the Spring operating system. SunSoft is working within OMG to define a standardized security solution which we plan to support in a future release of NEO Network.
The ORB provides a uniform way of defining and accessing objects in the same process, on the same computer, or across a network. Interfaces to objects are separated from their implementation. This allows the same mechanisms to be used to access all services — everything becomes an object.
Access to networked objects is by means of object references. Object references are opaque data structures generated by the ORB which are used to identify the target object of a request. They contain enough information for the ORB to efficiently find the object. Unlike RPC mechanisms, this is a dynamic process — object location and communication are not hard-wired.
NEO Network supports C and C++ mappings including full Any support (all CORBA data types). In addition, C++ interfaces are provided for interpreting TypeCodes.
The remote transport is based on TLI. Local transport is based on shared memory. Client cancellation is supported for both remote and local transport. Retry and rebind exceptions are handled, allowing clients to resubmit requests if a server process crashes or the ORB's Basic Object Adaptor (BOA) becomes unavailable.
The NEO Network ORB provides the basic CORBA::Object and CORBA::ORB APIs. These provide operations for such things as stringify/destringify object references and translations functions for TypeCode and Any. The Environment interface handles exception data. The Principal interface supplies a client invoker's ID.
The NEO Network ORB also provides built-in administration interfaces including those for BOA database inspection, consistency checking, backup and restore, and for obtaining server process runtime addressing information for debugging purposes.
The BOA causes the activation and deactivation when needed of server processes, object implementations and instances, and dispatches calls to methods through `skeleton' code. Multiple activation models are also supported.
The BOA is also responsible for generating and interpreting objects references and the maintenance of object reference information including up to 1KByte of associated persistent Reference Data. NEO object references are automatically persistent across server process activations.
In addition to the standardized BOA API, the NEO BOA provides upwards-compatible extensions that include support for subobjects and the ability to block new requests to enable MT coordination for object-critical sections.
The Interface Repository supports full type safety and internationalization and enables runtime type checking. Distributed application evolution is provided via major-minor interface version numbering and interface inheritance (and programmatic use of narrowing).
The Dynamic Skeleton Interface (DSI) enables the delivery of requests to an object implementation that does not have compile-time knowledge of the type of the object it is implementing. This allows all requests on one or more object types to share the same invocation code. This code can use narrowing with runtime type checking using the Interface Repository. DSI is useful for building inter-ORB bridges, debugging, interposing of objects, implementing objects with interpreters and scripting languages, and dynamically generating implementations.
SunSoft has supplied, in source form and free of licensing charges, a portable reference implementation of an engine for the CORBA 2.0 mandatory inter-ORB protocol (the Internet IOP) for networked ORBs. (The IIOP is the TCP/IP transport mapping of the CORBA 2.0 General IOP or GIOP.) This software formed the basis for the multivendor interoperability demonstration at the 1995 ObjectWorld, in San Francisco.
The Internet IOP Engine does the work to generate, receive, and handle the CORBA 2.0 standard protocol and is composed of four parts: a CDR (Common Data Representation) marshaling engine, a TypeCode interpreter, an Internet IOP Engine framework, and modules that enable the engine framework and the CDR marshalling engine to send, receive, and dispatch Internet IOP messages.
The Internet IOP software is written in C++ and is highly portable. The software has been compiled using: SPARCworks (for SPARC) and PROworks (for x86) C++ 4.0.1, Borland C++ 4.5, GNU C++ 2.6.3, and Visual C++ 2.0 on the following operating system platforms: Solaris 2.4 (both SPARC and Intel platforms), SunOS 4.1 on SPARC, Linux (1.1.47 and later) on 486 hardware., NEXTSTEP 3.2, Windows NT and Windows 3.5. To retrieve the software, send an electronic mail message with the subject help to iiop-bridging@omg.org and the mail server will respond with instructions, or use anonymous FTP to connect to the ftp.omg.org server.
As a particular example of this, the NEO Network Object Services allow generic tools and application frameworks to use and manipulate independently-developed off-the-shelf objects and services. Such tools and frameworks need not have any other special additional knowledge about the objects and services other than that they conform to the standardized object service interfaces.
NEO Network provides implementations of a rich set of generally useful services:
Other OMG CORBAservices planned for future releases include:
Because naming contexts can be named in other naming contexts, the Naming Service supports hierarchical naming schemes for objects and naming contexts. Graphs of naming contexts can be supported in a federated fashion. This scalable design allows the distributed, heterogeneous implementation and administration of names and naming contexts.
A canonical representation for compound names is used such that no particular name syntax is mandated. This, and the provision of a name `kind' attribute, facilitates application localization and places minimal constraints on higher-level name policies.
Push-style and pull-style delivery models and event fan-in (collect) and fan-out (multicast) are supported. Event content is IDL type Any. Typed event channels extend basic event channels to support typed interaction. Extended interfaces also allow event channels to be chained or piped together by third-parties without the involvement or knowledge of the suppliers or consumers.
NEO Network includes two Event Service implementations with different qualities-of-service: (1) fully persistent, and (2) transient events, persistent connections. Their design is scalable and is particularly suitable for distributed environments. There is no centralized server or dependency on any global service.
A PropertySet is a `first class' networked object that maintains a set of key-value pairs. The keys are strings and values are IDL type Any. The PropertySet interface defines operations to create properties, get and set property values, delete properties, enumerate the properties in the set, and destroy the property set. PropertySet objects can easily be shared with other applications.
Two common kinds of relationships are predefined: containment and reference. Examples of these are a document that contains an image and a table, and a document that references an appendix. The service is extensible and developers can define additional kinds of relationships.
The service defines two new types of objects: relationships and roles. A role object represents an object in an relationship. A relationship object is created by passing a set of roles to a relationship factory. Type and cardinality constraints can be expressed and checked and referential maintenance is supported.
Relationships are established in a way that does not require the involvement of objects being related. Because relationships are first class objects themselves, third parties (e.g., utility tools and object browsers) can traverse and manipulate the connections between the objects. Navigation performance and availability is comparable to the direct use of object references; role objects can be collocated with their objects and need not depend on a centralized repository of relationship information. As such, navigating a relationship can be a local operation.
The Relationship Service also supports traversals of graphs of related objects and thus provides the basis for compound operations.
The client program's model of creation is defined in terms of factory objects. A factory is an object that creates another object. As with any object, factories have well-defined IDL interfaces. The LifeCycle Service also includes the definition of an interface for a generic factory. This allows for the definition of standard creation services.
Compound life-cycle operations address copying, moving and deleting objects that are connected to other objects by relationships. Operations are propagated in one of three ways: none, shallow, and deep. Each type of relationship defines the required propagation behavior (e.g., copying of contained objects but not referenced objects).
NEO Services is a comprehensive development framework and associated shared libraries for networked objects and shared services. The development framework is employed by the NEOworks Networked Object Constructor. The shared libraries make up the NEO Services runtime system in Solaris NEO.
Unique to NEO, NEO Services is fully compatible with CORBA and enables full, simplified use of the NEO Network object infrastructure. It automates and makes transparent functions that an application developer would normally need to write in the areas of:
Workgroup Support allows access to shared services by enabling services to be registered in a well known place and found using the NEO Services Shared Service Finder. In this way, the need for applications to have a detailed knowledge of the system name space is eliminated.
Services (i.e., named objects) are registered at install time or runtime in a well known place. Applications can then dynamically find a service that is available to run in an appropriate server process. A service can be local to a computer or shared by a workgroup. A mode can be selected that controls whether a deployed service or a version under development is found.
The Shared Service Finder enables the relocation of services without needing to modify or recompile client code. In this way, service requests can be distributed to the most appropriate resource in a workgroup and dynamic load balancing is facilitated.
Server Availability automates server process startup on arrival of a request for any object in a server program as well as server process shutdown after a period of inactivity. The timeout (i.e., maximum idle period) is configurable per server process. The process waits for all objects in the server process to be deactivated before shutdown occurs. The wait interval and shutdown retry cycle time are configurable.
Because server availability is handled in a standardized way, the system can automatically manage and recover resources such as memory. In conjunction with the NEO Services Persistent Object Availability, the use of system resources is minimized.
Persistent Object Availability automates support for object life-cycle create and destroy, and object instance and implementation activation. It automates the activation of the object implementation and instance on the arrival of a request. A servant C++ object implementing the operations of the object's interface, transient data and other functions is automatically instantiated when an object is activated, and destroyed when the object is deactivated.
Persistent Object Availability also automates the deactivation of objects after a configurable period of inactivity. The timeout (i.e., maximum idle period) is configurable per object implementation. It transparently handles thread quiescing and waits for all pending operations to complete using a configurable wait and retry cycle time.
Optional transparent persistence of an object's state is provided based on the NEO Data Store Manager. This provides automatic atomic update at timed intervals and before deactivation of the object. The time interval is configurable per implementation. In addition, an infrastructure is provided to support custom persistence. All the hooks necessary to incorporate custom persistence mechanisms are provided to address cases where more control is needed over performance and the handling of data formats and legacy data.
Based on technology provided by Object Design, Inc., the Data Store Manager is designed to efficiently support development models in which applications are composed of many fine-grain objects comparable in size and complexity to typical C++ objects. Data objects can contain pointers to other data objects, allowing users to create persistent representations of complex, linked data structures in a natural manner.
A subset of IDL, called the Data Definition Language (DDL), is used to define the persistent state in terms of `data objects'. The IDL language binding approach is used to provide client bindings for a wide range of architectures and programming languages. Stored data maintains the same level of type safety as that provided by IDL.
Applications can create `data stores' (the unit of storage) in any part of the file system to which they have access. Transparent to clients, data objects are cached in local memory. Access to individual attribute values is essentially at the speed of native programming language calls. Modifying the persistent state of an object is done by simply modifying the C++ state of the object in memory — the rest is automatic and transparent.
Concurrent access to clusters within a data store is supported, making it ideally suited for supporting NEO multithreaded server programs. Automatic atomic updates provide a two-phase commit protocol, in anticipation of distributed transactions involving multiple services. Either all the changes made within an update are recorded, or none of the changes are recorded. A server process can be atomically updating several clusters with different schema definitions concurrently.
Based on the OMG CORBAservices Persistent Object Service specification, the Data Store Manager is a upwards-compatible subset of the object database specification developed by the Object Database Management Group (ODMG). An object implementation can therefore be easily upgraded as application requirements evolve.
Three different locking policies are supported: mutex (default), reader-writer, and fine grain. The locking policy is selectable on a per object implementation basis. Scoped locks are supported: with mutex and reader-writer locking, locks are automatically released when out of scope of the locking variable, or when the variable is destroyed.
Server Management completely takes care of server management and application management functions that a server program developer would otherwise need to provide. It enables the status of computers, server processes, and objects to be interactively monitored, administered, and managed by Solstice NEO tools.
With NEO Services, server processes can be activated and shutdown manually, the current status of a server process can be queried, object tracing and message logging can be turned on or off, and the persistent state (transparent and custom persistence) of objects in the server process can be backed-up and restored without any programming by the application developer.
Installation steps that are automated include the registration of server programs with the NEO Network ORB, the installation of IDL information associated with server programs in the NEO Interface Repository, and the registration of shared services for access via the NEO Shared Service Finder.
The NEO Application Installation builds on the easy-to-use SVR4 packaging concept, providing a familiar and reliable method for installing and deinstalling software packages. Applications and objects are installed and their availability automatically registered, allowing seamless upgrading with minimal impact on users.
Solstice NEO extends Sun's strategy of using the network to manage the network itself by using objects to manage objects. Solstice NEO adds capabilities for the administration and management of networked applications and shared services to the Solstice product family. With Solstice NEO, resources can be monitored and controlled from any point on the network, improving responsiveness and reducing costs. System, workgroup, shared service, and application management capabilities are supported.
A full set of administration and management tools provide for one-step system and application installation, full backup and restore, and extensive on-line help. Both command line and graphical user interface tools are provided to facilitate both an automated, scripted method, or a graphical, interactive browsing approach. Computers can be upgraded incrementally so that the entire network need not be affected at once. Implementations can be evolved in a way that allows multiple versions to coexist in the same server program, and multiple server programs to coexist as separate processes.
Solstice NEO provides a comprehensive set of functions through a suite of three tools: NEOadmin, ServerViewer, and NameViewer. These tools are briefly described below, and the functionality they provide is described in the sections that follow.
Backups are run as a background process on each computer. A two phase process handles problems arising from the distributed nature of the data and ensures the successful completion of the backup or restore. The status of backups can be queried and backups can be removed (i.e., archived).
These packages are installed on a computer using the Solaris visual Software Manager tool. Application upgrading and deinstallation are also supported.
Automated install-time steps include the registration of server programs with the NEO Network ORB, the installation of IDL information associated with server programs into the NEO Interface Repository, and the registration of shared services for access via the NEO Shared Service Finder. Optional custom scripts are also supported to `populate' naming contexts with required objects. These scripts are run once an application is installed and the associated server programs registered.
Servers processes can be put on hold (e.g., for upgrades), released, shutdown, and restarted (e.g., to restart a hung server). The Server Configuration File can also be displayed which contains trace, logging, and server shutdown information.
The Common Object Request Broker: Architecture and Specification, Object Management Group, 1994.
NEO Programming Guide, Beta Version, SunSoft, Inc., May 1995.
NEO Systems Management Guide, Beta Version, SunSoft, Inc., May 1995.
NEO Tutorial, Beta Version, SunSoft, Inc., May 1995.
NEO System Installation, Beta Version, SunSoft, Inc., May 1995.
NEO Programming Interfaces Reference, Beta Version, SunSoft, Inc., May 1995.
Solaris NEO Product Family, SunSoft, Inc., May 1995.
Workshop NEO Development Environment, Product Overview, SunSoft, Inc., January 1996.
Solaris OpenWindows: OpenWindows V3 Collection: Release Reports and White Papers, Part Number 91021-0, SunSoft Inc.
Solaris SunOS 5.0: SunOS 5.0 Multithreading and Real-Time, Part Number
91025-0, SunSoft Inc.
Solaris ONC: Design and Implementation of Transport-Independent RPC, Part Number 91028-0, SunSoft Inc.
Solaris SunOS: SunOS 5.0 Release Report, Part Number 91023-0, SunSoft Inc.
The ToolTalk Service, Part Number 91022-002, SunSoft Inc.
Introduction to the ToolTalk Service, Part Number 91031-002, SunSoft Inc.
Project DOE: Distributed Objects Everywhere, Part Number 91035-0, SunSoft Inc.
The ToolTalk Service: An Inter-Operability Solution, Part Number ISBN 013-088717-X. SunSoft Press/Prentice Hall, Englewood Cliffs, NJ.
ToolTalk and Open Protocols: Inter-Application Communication, Part Number ISBN 013-031055-7, SunSoft Press/Prentice Hall, Englewood Cliffs, NJ (June 1993).
An Overview of the Spring System, James G. Mitchell, et al, SunSoft, Inc., 1994
Copyright 1996 Sun Microsystems, Inc., 2550 Garcia Ave., Mtn. View, CA 94043-1100 USA. All rights reserved.